There exist reporting tools that generate reports of filtered data from underlying data sources. These tools often allow users to navigate from a source report to a target report, using values selected in the source report to filter data in the target report. This type of navigation is commonly known as “drill-through”. By drilling through, users can explore or browse items in the reports. For example, when two reports are in a master/detail relationship, by clicking an item in the master report, the user can reach the details of the clicked item in the detail report. The component from which drill-through is initiated is referred as the drill-through source and the component in which drill-through is terminated is referred as the drill-through target. This relationship between a drill-through source and target is known as a drill-through path. A component may act as both drill-through source and target, such as in a parts explosion, in one drill through path. A component may be a drill-through source in one drill-through path, and a target in another drill-through path. A component may participate in an arbitrary number of drill-through paths.
In order to provide drill-through capabilities in their application, a report designer or author needs to predefine the drill-through paths between the reports that form the application. Generally speaking, a drill-through path identifies a single target object (such as a report) and may also provide parameter mappings which allow the target to filter its data based on data values provided by the source. It may also provide a scope qualifier that controls when the drill-through path may be used. A drill-through path need not specify a source, since it is implicit, i.e., for authored drill through, the source is the report that contains the drill-through path, and for modeled drill through, the source is any object based on the package that contains the drill-through path.
Authors of drill-through target reports need to define parameterized filters to accomplish drill-through.
There exists a report management system that can automatically construct filter expression strings that are passed to a drill-through target based on the parameter values specified on the drill-through request. The drill-through target then attempts to parse the expression strings, matching names to known metadata objects. If a name cannot be found, the expression (or part thereof) is not used in the drill-through target to filter the data set. Such a system uses a heuristic to determine how parameter values are matched to model items in report filters. This heuristic based approach offers a simple authoring experience at the cost of a trial and error runtime experience. Because of this laissez-faire approach, there is no need to define parameters in such a report. The advantage of this approach is the elimination of any upfront authoring costs and complexity and runtime binding of drill-through parameters to the target. The disadvantage is that the drill-through experience can change if either the source or target is changed, either as a result of adding/removing items or renaming existing items in either source or target.
A different existing system provides a predictable runtime experience but requires extensive authoring. Report authors need to be conscious of the implications of drill-through when authoring reports. In particular, authors need to define a significant set of parameterized filters in each report to satisfy the wide variety of drill-through parameter value combinations required by all the drill through paths with the report as the target. Defining too many parameters can make a report too difficult to use in stand-alone scenarios. Although these filters can be declared optional, users are still often forced to navigate through a significant set of prompts before the drill-through target report is executed. Authors are forced to trade-off drill-through flexibility for a simpler stand-alone experience. In the worst case, authors need to create multiple reports for the same data set: e.g., one with many parameterized filters to support a rich drill-through experience, and a second with a small subset of these filters to support the stand-alone experience.
It is therefore desirable to provide a mechanism to manage drill-through targets that reduces manual authoring of target filters and distributed specification of target filters, and provides improved performance when reports are heavily parameterized.